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ABSTRACT 

The flight control consoles in mission 
control at NASA's Johnson Space Center 
(JSC) have evolved in sophistication to 
the level where "expert sy terns" are now 
being incorporated into them as "flight 
controller assistants." 

This paper describes the evolution of a 
gateway node, designed to obtain and redis- 
tribute numerous kinds of data provided by 
Mission Control computers over a laser-op- 
tical network to enable rapid-prototyping 
development of the above application ex- 
pert systems. 

This automated data distribution and man- 
agement system serves as an effective buf- 
fering system for assuring the necessarily 
separate requirements of the operational 
and developmental environments. This is 
accomplished through the evolutionary en- 
hancement of the gateway's ancillary mon- 
itoring and control expert system that was 
originally designed to "watch and react" 
to system anomalies in the operational 
state, but whose role has been substan- 
tially expanded. 


BACKGROUND 

The Mission Control Center (MCC) , at 
NASA/JSC has traditionally provided flight 
data via digital tape to applications sub- 
scribers outside of the center. Although 
called near-realtime data, the time delays 
required to prepare the tapes limited 
their use for playback and post-flight 
analysis modes. A growing demand for time- 
ly data during the flights necessitated 
the development of a local area network 
(LAN) to ship to sites remote from the MCC 
the kinds of data that had only been avail- 
able to the MCC realtime support laborator- 
ies adjacent to the MCC. 


A prototype laser-optical LAN was in- 
stalled to test the feasibility of pro- 
viding high-quality realtime and near-real- 
time data to remote subscribers. Known as 
the MITS LAN, its two-year test program 
has proven successful, enabling the system 
to be brought up to operational status. 

This means that remote nodes will be able 
to serve as both developmental and opera- 
tional extensions of the MCC. A rigorous 
system of configuration management has 
been designed and is in the process of 
being installed to ensure that only pro- 
perly verified and validated applications 
programs are maintained within the opera- 
tional MCC environment. 

Not surprisingly, the new concept of the 
MCC distributed LAN provided a resource 
that piqued the imaginations of Mission 
Planning and Analysis Division (MPAD) 
personnel working in the environment of 
developing expert systems for use as 
"assistants to" flight controllers. They 
came to view their node of the MITS LAN as 
a means to both develop their prototype 
programs and to eventually run them in 
actual operational states. At the same 
time the level of sophistication of the 
anticipated programs accelerated. 

Other groups within MPAD were given the 
responsibility to ensure that data emana- 
ting from the MCC-distributed LAN node to 
MPAD were timely and of sufficient relia- 
bility to ensure meaningful development of 
expert systems and other application pro- 
grams. A prototype data distribution and 
management workstation concept was devised 
in conjunction with the prototype of the 
MITS LAN. This paper describes the three 
phases of data workstation development for 
the automated data distribution and manage- 
ment (ADDAM) system and the design of an 
associated monitoring and control expert 
system, the Effective Evaluation Expert 
(EEVE) , that is responsible for ensuring 
data integrity. 
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THE FIRST PROTOTYPE 

Figure 1 depicts the initial ADDAM work- 
station concept devised in conjunction 
with the proof -of -concept MITS LAN, Work- 
station software to accommodate one "walk- 
up" user at a time was provided on a 
HP9000 minicomputer. Through a series of 
displays, menus and entryforms, the user 
selected types of data desired and a stor- 
age medium for that data (either disk 
files or digital data tapes) . Gateway 
software was provided on the HP9000 that 
serves as one of the MITS LAN nodes. The 
gateway's function was to ensure that only 
appropriate data requests were transmitted 
to the MCC and within the correct design 
frequency load limits. 


The idea for the addition of an expert sys- 
tem to this configuration resulted from 
certain anomalies within this earliest ver- 
sion of the MITS LAN. Frequent abrupt da- 
ta terminations and dropouts necessitated 
development of a monitoring and control 
system to assess system integrity and pro- 
vide remedial actions as required. Writ- 
ten in the programming language LISP, the 
Effective Evaluation Expert (EEVE) was run 
concurrently on a Symbolics 3640 tied to 
the gateway HP9000 via a direct cable/- 
RS232 interface. In this simplest of 
expert system configurations, EEVE 
provided what could be termed "operator 
emulation." Figure 2 shows "the face of 
EEVE" as manifested within the graphics 
environment available on the Symbolics 
computer. Status update windows and mouse 
activation fields were provided to enable 
observation of the performance of the 
expert system during operation. 

Although both the MITS LAN and workstation 
system prototypes proved effective, both 
necessarily were limited by the proof-of- 
concept design constraints. The prototype 
workstation system could only serve one us- 
er at a time and data could only be stored 
before usage. 


THE CURRENT PROTOTYPE 

The increasing sophistication of the 
user/application community during the test 
phase of the MITS LAN prototype necessi- 
tated an expansion of the working concept 
of the MCC workstation system to accommo- 
date their needs. Figure 3 shows the en- 
hanced version of the workstation system 
prototype currently under assembly. Nota- 
ble in this design are increased responsi- 
bilities and capabilities for all previous 
processors as well as the addition of new 
processors, specialized workstations, and 
improved techniques for moving data and 
information over the local MPAD LAN. 


On the workstation side of the MPAD LAN, 


multiple MCC Application workstations are 
separate from the MCC Data Management 
workstation; the latter comprising a 
Britton Lee database machine hosted by a 
HP9000 . The data management workstation 
is utilized to store data types and se- 
quences for playback during specialized 
analyses or during flight simulations. 

Each application workstation can provide 
data directly to automated applications, 
particularly realtime expert systems, on a 
datastream basis, through the new Enhanced 
Development Environment Networked Node 
(EDENN) processors in conjunction with the 
expanded capabilities of the ADDAM 
gateway. 

On the gateway side of the local MPAD LAN, 
the ADDAM processors have been upgraded to 
service multiple workstations with an 
expanded list of data types and varia- 
tions. Within the automated maintenance 
monitoring and control milieu, the EEVE 
systems design role now calls for hypo- 
thesis construction and testing beyond 
mere operator emulation. In addition, the 
EEVE system will be rehosted from the 
Symbolics 3470 (in LISP) , to the same 
HP9000 containing the ADDAM processors (in 
the inferencing engine/language CLIPS) , 
that also serves as the node terminal to 
the MITS IAN. 


THE ADVANCED PROTOTYPE 

Even as the current prototype is under 
construction, demands for increased per- 
formance have been requested from both the 
data provider side of the chain (the sys- 
tem herein described) , and the data util- 
izer side (the application expert sys- 
tems) . Consequently the plan for an even 
more advanced operational structure is now 
also in preparation. Figure 4 illustrates 
the increased complexity over the current 
prototype. 


It is important to note the addition of a 
generalized communications interface tech- 
nology among the gateway and the work- 
stations. Called the Remote Information 
Interchange Buffer (RUB) processors, they 
intermediate among the data-oriented exec- 
utives (ADDAM and EEVE) and the networks 
utilized to transfer data and advisories. 

As such, the RIIB's serve as "session mana- 
gers" on behalf of the executives within a 
User Datagram Protocol/ Internetwork Proto- 
col (UDP/IP) networking environment. Also 
planned for the RIIB's are generalized dis- 
play terminal support functions that allow 
for the dynamic reconfiguration of termi- 
nals within the Transmission Control Pro- 
gram/Internetwork Protocol (TCP/IP) net- 
work environment. Figure 5 illustrates 
that using the accepted International Stan- 
dards Organization Open Systems Intercon- 
nection Protocols (ISO OSI) network commun- 
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ications scheme, both ADDAM and EDENN com- 
prise Application Level 7, whereas the 
RUB occupies the Session and Presentation 
Levels, 5 and 6. 

This new uniformity in communications en- 
ables EEVE to take on the added task of 
network failure response. In this mode, 
EEVE can restart applications by rerouting 
the users 1 terminals via the network to 
the new hosting node. To accomplish this, 
EEVE accesses the Data Management worksta- 
tion database for a local configuration 
management library. 

Both the ADDAM and EEVE systems have full 
backup versions, as shown in Figure 4, 
that are fully ready to step in should the 
"master" gateway/monitor fail. When the 
backup EEVE senses that the current master 
has failed, it promotes the backup ADDAM 
to master status, reboots, and arranges 
for the switchover of data and advisories 
to any and all workstations waiting in 
abeyance. New backup versions of ADDAM 
and EEVE are then created and placed in 
readiness. 

Specialized versions of EEVE, called EEVE 
II, have been added to the workstations to 
provide the levels of interpretation of 
the flight-specific environment for the 
online application expert systems. This 
focuses EEVE 1 s duties on the gateway to 
levels of interpretation regarding flight 
control host activities and network and 
performance configuration. 


Importantly, this design embodies two par- 
allel and interdependent means of communi- 
cation as symbolized by the solid and dot- 
ted lines. The solid lines, connecting 
the realtime data and advisory processors, 
including ADDAM and EDENN, symbolize the 
autonomic neuralnet system (ANS) side of 
the entire configuration. Conversely, the 
dotted lines represent a "virtual LAN" 
that connects EEVE, EEVE II and even the 
online application expert systems and, as 
such, symbolize the central neuralnet sys- 
tem (CNS) side of the configuration. This 
design allows the CNS to perform symbolic 
processing without hindering the realtime 
response of communications interfaces. It 
also enables the various expert systems to 
converse, negotiate, and even "argue" 
about network priorities and flight envi- 
ronment realities. 


AN EXPERT CONVERSATION 

The following scenario is presented to 
illustrate the levels of interpretation 
that will exist in the symbolic discourse 
between application expert systems and 
EEVE/ EEVE II: 


The application E/s innocently asks 
about the status of its flight (fear- 
ing the worst since data is missing) 
to the local EEVE II system. EEVE II 
discovers that there are holes in its 
fact database and makes further in- 
quiries to EEVE at the gateway. 

The application system would begin 
with a message to the EEVE II on the 
local workstation: 

FROM : Application E/S: USER43 

TO: EEVE II @ MCC 

Workstation: FM8 

(QUERY FLIGm^STAIUS) 

(REQUESTOR SESSION USER43) 


EDENN automatically adds the session 
identifier, USER43 , as the inquiry is 
forwarded to EEVE II. 

EEVE II consults its database, 

(DATA-REQUIREMENT USER43 NRT) 
(DATA-REQUIREMENT USER43 TRJ 
(CYCLIC-STREAMS 

(HIGH-SPEED-MISC) ) 

(DEMAND-STREAMS 

(ATTITUDE-TIMELINE 
VECTOR-ADMIN-TABLE) ) ) 
(DATA-REQUIREMENT USER43 CAS) 


(FLIGHT-WQON USER43 FLIGHT 71-B) 


and concludes that it needs to consult 
EEVE at the gateway about the status 
of the Near Realtime Telemetry (NRT) , 
trajectory (TRJ) , and Calibrated 
Ancillary Telemetry System (CAS) data 
streams for flight 71-B. 


Thus EEVE II sends the following 
message to EEVE: 

FROM: EEVE II Q MCC 

Workstation: FM8 

TO: EEVE @ MCC Gateway 

(QUERY DATA-STREAM-STAIUS FLIGHT 
71-B NRT) 

(QUERY DATA-STREAM-STAIUS FLIGHT 
71-B TRJ) 

(QUERY DATA-STREAM-STAIUS FLIGHT 
71-B CAS) 

(REQUESTOR WORKSTATION FM8) 

The last fact is added by ADDAM as the 
message is forwarded to EEVE. 
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Correspondingly, EEVE consults its 
database at the gateway, 

(DATA-STREAM NRT FLIGHT 71-B 
STATUS ACTIVE AT 17:08) 

(DATA-STREAM TRJ FLIGHT 71-B 
STATUS UNKNOWN AT 17:05) 

(DATA-STREAM CAS FLIGHT 71-B 
STATUS PENDING AT 17:07) 

(CONTINGENCY FLIGHT 71-B TRJ 
NO-RESPONSE AT 17:05) 

(CONTINGENCY FLIGHT 71-B TRJ 
CHECKPOINT-WARNING AT 
16:58) 

(CONTINGENCY FLIGHT 71-B CAS 
RESTART-REQUESTED AT 
17:07 ) 

and would have to shrug its allegor- 
ical shoulders if it were not for the 
sudden entry of a new fact and the ex- 
piration of a timer (all sensed by 

ADD AH) — 

(CONTINGENCY FLIGHT 71-B CAS 
RESTART-ACKNCW1EDGED AT 
17:10). 

After a few simple rules fire EEVE 
then has the following facts with 
which to resolve the question: 

(RESOLUTION FLIGHT 71-B CAS 
RESTART-CONFIRMED AT 
17:10) 

(RESOLUTION FLIGHT 71-B TRJ 
CHECKPOINT-ASSUMED AT 
17:10) 

(DATA-STREAM CAS FLIGHT 71-B 
STATUS IN-RESTART AT 
17:10) 

(DATA-STREAM TRJ FLIGHT 71-B 
STATUS (CHECKPOINTED .95) 

AT 17:10) . 

The rule operating for the pending sta- 
tus on the CAS data stream is clear 
enough. However, the assumed check- 


point rule is obviously one of inter- 
pretation — guessing — on the part 
of EEVE. Thus EEVE asserts that the 
flight control host system supporting 
the trajectory data stream must be in 
the grips of a checkpoint procedure. 
EEVE further notes that it does not 
know this with certainty, but rather 
that it feels reasonably sure (.95) 
that this must be the case since a 
checkpoint warning was received some 
12 minutes previously. 

It is not implied that EEVE is imple- 
mented using fuzzy logic. EEVE simply 
provides a confidence level for its de- 
ductions that may or may not be used 
by an EEVE II or application expert 
system when making further decisions. 

At any rate, EEVE returns what it 
knows about flight 71-B to the FM8 
workstation: 


FROM: EEVE Q MCC Gateway 

TO: EEVE II @ MCC 

Workstation: FM8 

(RESPONSE-IO WORKSTATION FM8 AT 
17:10) 

(DATA-STREAM-STATUS FLIGHT 71-B 
NRT ACTIVE AT 17:08) 
(DATA-STREAM-STATUS FLIGHT 71-B 
CAS IN-RESTART AT 17:10) 
(DATA-STREAM-STATUS FLIGHT 71-B 
TRJ (CHECKPOINTED .95) AT 
17:10) 


The EEVE II at FM8 now has enough in- 
formation to respond to USER43: 

FROM: EEVE II Q MCC 

Workstation: FM8 

TO: USER43 Q MCC 

Workstation: FM8 

(RESPONSE-TO SESSION USER43 AT 
17:10) 

(FLIGHT-STATUS FLIGHT 71-B 
ACTIVE AT 17:10) 


While the application system received 
an answer to its question, it turns 
out that USER43 is sophisticated 
enough to ask even more detailed ques- 
tions: 

FROM: USER43 @ MCC 

Workstation: FM8 


18 



TO: EEVE II @ MCC 

Workstation: FH8 

(QUERY DATA-STREAM-STAIUS TRJ) 

(QUERY DATA-TYPE-STAIUS 
(HIGH-SPEED-MISC 

VECTOR-ADMIN-TABLE NET) ) 

(REQUESTOR SESSION USER43) . 

To which EEVE II can directly respond: 


FROM: EEVE II 0 MCC 

Workstation: FM8 

TO: USER43 @ MCC 

Workstation: FM8 

(RESPONSE-TO SESSION USER43) 
(DATA-STREAM-STATUS FLIGHT 71-B TRJ 
(CHECKPOINTED .95) AT 17:10) 
(DATA-TYPE-STATUS FLIGHT 71-B 
( (HIGH-SPEED-MISC CYCLIC 
HALTED AT 17:10) 
(VECTOR-ADMIN-TABLE ON-DEMAND 
HALTED AT 17:10) 

(NET ON-DFMAND ACTIVE AT 
17:08)))!! 


IN CONCLUSION 

It is evident from the foregoing dialogues 
that much work has yet to be done to reach 
the level of sophistication implied by the 
symbolic information transfer that is tak- 
ing place among the expert systems. It 
will be no small challenge to build the 
domains of interpretation required of the 
expanded EEVE and the new EEVE II's. Much 
proof-of-concept testing has yet to be in- 
spired and embraced. Even before the ba- 
ses for interaction are established among 
EEVE and the EEVE II's over the "virtual 
LAN," the servicing interfaces must be 
worked out between an EEVE II and the ap- 
plication expert systems that reside on 
its workstation. This, in itself, is a 
substantial undertaking because of the 
amount of time required to meet with the 
application expert system designers in or- 
der to understand their special needs and 
requirements. One such project, currently 
under way, has resulted in the requirement 
for a time synchronization processor to be 
added to an EDENN system. 

Optimistically, once the central neuralnet 
is in place in even rudimentary form, thus 
linking all of the service and application 
expert systems together, the symbol ic-or- 
iented design will enable a continuous and 
evolutionary growth in capability as time 
and resources permit. 


ABBREVIATIONS, ACRONYMS AND TERMS USED IN 
THIS PAPER 

ADDAM - Automated Data Distribution and 
Management system 

ANS - Autonomic Neuralnet System 

ATT - Attitude Table data 

CAS - Calibrated Ancillary System 
CM - Configuration Management 

CNS - Central Neuralnet System 

COTS - Commercial Off-The-Shelf 

DB - Database 

DM - Data Manager 

EDENN - Enhanced Development Environment 
Networked Node 

EEVE - Effective Evaluation Expert 
E/S, ES- Expert System 
HP9000 - Hewlett Packard minicomputer 
IP - Internetwork Protocol 

IPS - Instrument Pointing System 

ISO - International Standards Organi- 
zation 

JSC - Johnson Space Center 

LAN - Local Area Network 

LLA - Link Level Access 

MCC - Mission Control Center 

MITS - MOD- I PS -TAC AN System (LAN) 

MNV - Maneuver table data 

MOC - Mission Operations Center 

MOD - Mission Operations Directorate 

MPAD - Mission Planning and Analysis 
Division 

MSD - Mission Support Directorate 
NASA - National Aeronautics and Space 
Administration 

NRT - Near Realtime Telemetry data 
OS I - Open Systems Interconnection 
Protocols 

RUB - Remote Information Interchange 
Buffer 

TACAN - Tactical Air Control and Naviga- 
tion system 

TCP/IP - Transmission Control Program / 
Internetwork Protocol 
TRJ - Trajectory data 

UDP - User Datagram Protocol 

VAT - Vector Administration Table data 

XNS - Xerox Network System 
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Figure 2 - The Face of EEUE 
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